System method and apparatus for portable digital identity

ABSTRACT

Two-way digital media devices typically store digital identifying data that identify the user to providers of content and interactive data. In the case of a Web browser of a personal computer, the digital identity is stored in the form of a plurality of cookies that are used by respective web sites to personalize the web site experience for each particular user. When a user is at a different computer, the digital identifying data is not available. In addition, other types of interactive devices, such as CATV settop boxes, cell phones, PDAs and the like, may not have enough non-volatile memory (persistent storage) to store the digital identifying data. In order to provide users with a portable digital identity, a digital identity server is provided as a server node on the Internet, which retrieves digital identifying data and downloads such digital identifying data to any device upon request. In such manner, the user&#39;s digital identity is portable and available at any computer or other digital device that is being used. The system digital identity server permits devices without sufficient non-volatile memory storage to download a digital identity for temporary storage in volatile memory, thereby providing a digital identity in devices without non-volatile memory.

FIELD OF THE INVENTION

[0001] The present invention relates to the field of portable electronicdevices and networked electronic communication.

BACKGROUND OF THE INVENTION

[0002] In using any kind of networked communication device, each userhas a user profile that defines a personalized electronic environmentfor that particular communication device.

[0003] For example, while surfing the Internet on a personal computer,each Web site supplies individual browsers with unique cookies thatstore identifying information in the user's Internet browser. Whenvisiting specific web sites, the cookies stored in the browser identifyeach individual to the web site. Based on the information stored in thebrowser's cookies, each Web site personalizes its contents according tothe individual Internet browser. An individual may select bookmarks orfavorite Web sites, which are stored on the individual's personalcomputer persistent memory (hard drive) and which further customize theelectronic environment to suit the user.

[0004] As another example of a personalized identity in a networkedelectronic environment, in a cable television (CATV) system, eachsubscriber or household subscribes to different programming. Somesubscribers have basic cable, while other subscribers have basic cableplus some premium channels. Each member of the household generally hasdifferent favorite channels. Additionally, some cable households havebroadband Internet access via CATV using a cable modem. In such case,the CATV settop, in communication with a computer at the CATV headend,acts as an Internet browser. However CATV settop boxes tend to havelimited computing capabilities, and in particular, CATV settop boxestend to have limited persistent memory in which to store personalizedinformation such as cookies.

[0005] As another example of a personalized identity in a networkedelectronic environment, a wireless cellular telephone system providesdifferent subscribers with different calling plans specifically selectedby the subscriber. Some cellular telephone networks also offer Internetconnectivity to their customers. However, as in the case of CATV settopboxes, cellular phones tend to have limited capabilities as Internetbrowsers, and in particular, tend to have limited persistent memorystorage for personalized information such as cookies.

[0006] When away from the home environment, the electronic environmentis different from that at home. For example, using a settop box in ahotel room means that the subscriber typically does not have access tofamiliar television programs or customized Internet interface. Borrowingor renting a cellular telephone means that the subscriber may not haveaccess to his regular calling plan, is unable to receive incoming callsusing his regular phone number, and does not have the customizedInternet environment as he would at home. Generally, when a traveler issurfing the Internet at a remote location, whether it be a computer, aremote CATV settop or a cellular phone away from home, Web sites thatnormally have customized content suited to the traveler, will notrecognize the individual Internet browser while at such remotecommunications device.

SUMMARY OF THE INVENTION

[0007] The present invention is embodied in a digital identity serveroperating as a node on a distributed computing network such as theInternet.

[0008] In accordance with the present invention, a user enters uniqueidentifying information into an electronic communication device. Forexample, an email address is unique to each person and entering an emailaddress uniquely identifies the individual to the electroniccommunication device. Furthermore, entering a password in addition to anemail address authenticates the user.

[0009] In order to personalize the electronic environment, theelectronic communication device forwards the user's unique identifyinginformation to the digital identity server via the Internet. The natureand capabilities of the given remote electronic communication device isalso forwarded to the digital identity server. The digital identityserver responds by transmitting a digital identity corresponding to theuser to the given electronic communication device. The received digitalidentity defines the services for which the user is authorized (e.g. inthe case of a CATV subscriber, the received digital identity includes alist of the premium channels that the subscriber is authorized to view).Furthermore, the digital identity server provides a level offunctionality suited to the capabilities of the particular electroniccommunication device. The electronic communication device receives thedigital identity of the user and personalizes its operation to suit theuser.

[0010] The electronic communication device that retrieves the digitalidentity of the user and personalizes its operation to suit the user maybe a CATV settop box, a cellular telephone, a computer, a video gameconsole, an Internet access terminal, a payphone, a vending machine orany present or future electronic communication device. In such manner,the digital identity of the user is made portable, and follows the userwherever the user may go providing the user with the same electronicenvironment accessible from any electronic communication device.

[0011] In addition, the portable digital identity system of the presentinvention facilitates the use of simplified electronic communicationdevices. In particular, electronic communication devices accessing theuser's portable digital identity may be implemented using very thinclient software and/or without persistent data storage, making theelectronic communication device smaller, lighter and less expensive.

[0012] The portable digital identity includes email preferences, emailaddress book and email client software settings, thereby presenting tothe user a seamless and consistent email environment. The portabledigital identity includes TV preferences, permitting the user to watchhis favorite shows and have his premium channels be available from anyhotel room. The portable digital identity includes preferred credit cardand shipping information (work and home addresses), as well as preferredcarriers and other preferences to facilitate eCommerce applications.

[0013] The portable digital identity of the present invention permitsthe user to access familiar services across different platforms. Forexample, the present invention permits cross platform authorization(e.g. TV to PC) so that the user may access HBO on a PC. That is, an HBOsubscriber may not only access HBO from any remote CATV settop, but mayalso access HBO on a PC (to the extent that HBO is available via abroadband Internet connection).

[0014] The portable digital identity of the present invention includesdemographic profiles and marketing data on user's activities andpreferences across devices and in real time. In such manner, forexample, an online newspaper viewed at a remote location, containsarticles of interest to the subscriber and presents demographicallytargeted advertising tailored to the interests of the subscriber.

[0015] The portable identity of the present invention may be used tocontrol TV appliances. For example, if a user normally records a giventelevision show on a weekly basis, that knowledge can be used toconstruct a profile of the user that is then mapped to the user'sportable digital identity and stored. The profile may then be used byother applications to target application content at the user the suitshis or her interests.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016]FIG. 1A is a block diagram of a system including a portabledigital identity server and a plurality of information appliancesforming a global computer network in accordance with the presentinvention.

[0017]FIG. 1B is a block diagram of a system embodying a portabledigital identity server in accordance with the present invention.

[0018]FIG. 2A is a block diagram further detailing the systemarchitecture of a system embodying a portable digital identity server inaccordance with the present invention.

[0019]FIG. 2B is a block diagram further detailing the implementation ofthe data access function of a system embodied in a portable digitalidentity server in accordance with the present invention.

[0020]FIG. 2C is a block diagram further detailing the implementation ofan other network adapter for use with a portable digital identity serverin accordance with the present invention.

[0021]FIG. 3 is a block diagram of three top-level software objects:account, machine and user for use in conjunction with the presentinvention.

[0022]FIG. 4 is a block diagram of the attributes of an Internet browsercookie for use in conjunction with the present invention.

[0023]FIG. 5 is a block diagram of an account data object for storing anaccount's properties and billing information in accordance with thepresent invention.

[0024]FIG. 6 is a block diagram of a machine data object to representingin interactive device for use in accordance with the present invention.

[0025]FIG. 7 is a block diagram illustrating a user data objectrepresenting a user of an interactive device or application inaccordance with the present invention.

[0026]FIG. 8 is a hierarchical representation of the digital identityobject model embodying the present invention.

[0027]FIG. 9 is a system block diagram illustrating the scalability ofthe present invented system using server groups.

DETAILED DESCRIPTION

[0028] As shown in FIG. 1A, the digital identity server 100 communicatesover a global computer network 114 (such as would include the Internetas part of the overall global network) with a plurality of user devices.Examples of user devices include a CATV settop 102, a satellite receiver104, a cellular phone 106, a personal digital assistant (PDA) 108,personal computer 110, video game console 112 or other client device113. Each user device connects to the Internet though anothercommunication network. For example, a CATV settop box 102 is coupledthrough a CATV system, while a personal computer 110 is typicallycoupled through the public switched telephone network. The digitalidentity server 100 also communicates via the Internet 114 with adigital identity database 118, an external database 116 as well as acommand server 120.

[0029] In operation, a user identifies himself to a user device 102,104, 106, 108, 110, 112. The user device 102, 104, 106, 108, 110, 112requests a digital identity from the digital identity server 100. Inresponse, the digital identity server 100 communicates with the commandserver 120 to determine the nature and characteristics of the requestinguser device 102, 104, 106, 108, 110, 112. The digital identity server100 then retrieves the digital identity information from either thesystem database 118 or an external database 116 and downloads it to therequesting user device 102, 104, 106, 108, 110, 112. After the initialdownload of a digital identity to user device, the digital identityserver 100 need not be involved except to download changes to update auser's digital identity.

[0030] In such manner, the digital identity server 100 mediates theuser's access to applications/services and data from a variety of userdevices ranging from a digital set-top box 102 to a portable personaldigital assistant 108 to a mobile/cellular phone 106 to a game console112 to a personal computer 110.

[0031] Applications include Video-on-demand (VOD), gaming applicationssuch as multi-player games, email, instant messaging, chat and broadcastbased enhanced TV applications. In video-on demand for example, a viewermay pause a movie at a given point. The pause point of the movie becomespart of the viewer's digital identity. When the viewer returns to watchthe rest of the movie, the viewer's downloaded digital identity containsthe pause point. As a result, the viewer is able to continue watch theremainder of the movie at a later time from any CATV settop 102communicating with the digital identity server 100.

[0032] Additional applications include using an e-wallet (where thee-wallet for a user is tied to his digital identity and stored in thesystem) and delivering targeted advertising applications (where theprofile of the user describing his interests and past behavior is tiedto his digital identity and stored in the system).

[0033] The range of data contained in the portable digital identityincludes the user's properties such as his preferences regarding the useof the device in question, his favorites data including the list offavorite applications and favorite Internet sites. The data includes theuser's cookies which facilitate access to internet sites, and the set ofapplications/services that the user may access including the propertiesof the user for a specific application/service.

[0034] The digital identity server 100 retrieves configurationinformation from the command server 120 about various types or classesof devices within the system, and applies configuration information as afilter when returning digital identity data back to the user device. Theset of applications and the generic user properties as well asapplication specific user properties are tailored take into account theprocessing power, network bandwidth and memory footprint capabilities ofthe communications device currently in use by the user. Thus, when theuser is on a powerful communications device such as a personal computer110, the list of applications available to such user includes the fullset of allowed or subscribed applications. When the user is on a lesspowerful device such as a set-top box 102 or a personal digitalassistant 108, the list of applications available to a user willtypically include only a lesser permissible subset of applications.

[0035] The digital identity of the user remains the same regardless ofthe device that the user is using at any point in time. Having aconsistent digital identity retrievable at any point by Internet access,allows the user to access his applications/services and data in aseamless and transparent fashion. Thus, even while “roaming” i.e. movingbetween multiple devices in his home, or to a device at a remotelocation such as a digital set-top box or game console at a friend'shome, or using a cellular phone/pager in his car, the user experiences aconsistent electronic environment.

[0036] Associated with the notion of a portable digital identity is thenotion of a General Services Architecture. The General ServicesArchitecture defines and describes the model that allows the use ofapplications/services and associated data by the user from their variousdevices. In particular, the General Services Architecture includes auser account that defines the applications and services to which theuser subscribes.

[0037] The digital identity server 100 and a General ServicesArchitecture allows the service provider/operator to dynamically defineand add new services/applications into their server-side infrastructure.Services are available dynamically to users based on a configurablepolicy that can be customized to suit the business needs of the specificnetwork operator or service provider.

[0038] Furthermore, access to the service can be controlled at a verygranular level all the way down to a specific device and a specificuser. User A may subscribe to the video on demand (VOD) service, butUser B may not be allowed access to the service or even be allowed tosubscribe to the service at all. If the user is a subscriber to aspecific service he may not be able to access the VOD service unless heis on a device that is actually capable of running that service as isdetermined by the digital identity server dynamically.

[0039] The digital identity of the user as implemented by the digitalidentity server 100 includes a rich object oriented programming modelthat provides high reliability and high availability and scales tomillions of users. The digital identity server 100 has easyextensibility to new client devices 113 and new server platforms andalso provides for easy integration with existing stores 116 of userinformation being maintained by service providers and operatorselsewhere on the Internet.

[0040] The overall digital identity system design is a four-tierarchitecture of clients 10, 10A, 12, 12A, adapters 18, 14, engine 22with application programming interfaces 20 (APIs) and database 24 shownin FIG. 1B. The digital identity server 100 provides a mechanism toprovide connectors to different devices 10, 12 (where client softwareresides) that can be hooked into the internal core digital identityengine 22. Such connectors are referred to herein as adapters 18, 14.

[0041] A digital identity software development kit (SDK) 16 permitsother clients 12 to write specialized adapters 14. The specializedadapter 14 is a protocol translator written by an other client 12 usingthe digital identity SDK 16 that uses standardized XML protocol tocommunicate with a standard digital identity adapter to the digitalidentity engine 22.

[0042] Client software may reside in devices other than user devices 10,12. In particular, a CATV system 11B can be a CATV client. In such case,digital identity software development kit (SDK) 16A permits aspecialized adapter 14A to be written that uses standardized XMLprotocol to communicate with a standard digital identity adapter to thedigital identity engine 22. As another example, a web site can be a website client 11A communicating with the digital identity engine 22 via astandard adapters 18.

[0043] The digital identity engine 22 is the component that handles allaccess to all data that adapters 10, 10A, 12, 12A (and thus clients) isstored on the server side. The core engine 22 and its digital identityAPIs 20 is written in Java to take advantage of Java DatabaseConnectivity (JDBC) as the primary mechanism for accessing the digitalidentity data.

[0044] Application programming interfaces (APIs) are available as partof the TV Navigator platform (including client-side JavaScript and JavaAPIs) and as part of the Connect Suite platform (the server-side Javabased, XML based and CORBA based APIs) that allow applications to beauthored on top of the digital identity platform. CORBA, an acronym forCommon Object Request Broker Architecture, is a type of object-orientedprogramming language system.

[0045] The digital identity server (100 in FIG. 1) further provides yetanother interface that can be implemented by third parties in order towrite specialized plug-ins (223 in FIG. 2A) to the digital identityserver 100. Specialized plug-ins are used to access (in a transparentmanner) information residing in external systems (234 in FIG. 2A) andincluding the legacy billing and SMS systems of the CATV operator (orother service provider).

[0046] The portable digital identity server 18, 20, 22 of FIG. 1B isshown in further detail in FIG. 2A (210). The digital identity Engine230 provides an application programming interface (API) 228 to clientadapter writers. The digital identity API is implemented as an efficientmeans for adapters to name, store, and control access to user data. Thedesign relies on a relational database to provide the storage andindexing of user data.

[0047] The digital identity engine 230 is what implements the API thatadapters 222, 224, 226 use to perform operations on data. Adapters aresoftware components that communicate with clients. Various adapters aredeveloped for the various clients that digital identity server 210supports. For example, standard adapters include a CORBA adapter, adigital television and cookie adapter 224 and an XML adapter 226. Another adapter 212 is created using the software development kit 214.

[0048] Various client software 202, 203, 204, 206 and 208 communicateswith the digital identity server 210 via a corresponding adapter. Forexample, provisioning application 202 and a digital identity controlconsole 203 interface through a CORBA adapter 222. A first generationdigital television client 204 (using a proprietary protocol) interfacesthrough a digital television and cookie adapter 224. A next generationdigital television client communicates with the digital identity server210 through an XML adapter 226 (using a standard version of ExtensibleMarkup language or XML) as would an other adapter 212. CORBA Clients usetheir own protocol, notably CORBA IIOP in COBRA adapter 222, rather thanXML/HTTP in adapter 226.

[0049] Similar to the operation of FIG. 1A, the command server 238 inFIG. 2A provides data on the nature and characteristics of therequesting user device. The digital identity server 210 then retrievesthe digital identity information from either the system database 236 oran external database 234 and downloads it to the requesting user device.

[0050] As shown in FIG. 2B, the digital identity engine 250 includes APIimplementation functions 252 responsive to the application programminginterface 251. The digital identity engine 250 further comprises a dataaccess layer 254 responsive to the API functions 252 to perform all ofthe mechanisms for abstracting or accessing data out of the backend(data storage).

[0051] The API implementation 252 communicates only with the data accesslayer 254 and not directly with the various back-end data accessfunctions such as Lightweight Directory Access protocol (LDAP) 258, 268,Java Database Connectivity (JDBC) 264, schema mapper 266, calloutmechanism 260 and system data cache 262. (Liberate Technologies, 2Circle Star Way, San Carlos, Calif. 94070). The design is quite general,in the sense that adding a new mechanism for accessing data wouldrequire no changes to the API implementation functions 252 or theadapters (18 in FIG. 1B).

[0052] A data access layer 254 in the digital identity engine 230provides the following functionality:

[0053] 1. Pools connections 253 to all data sources, including Groupdatabases 272B, System database 272A, and Lightweight Directory Accessprotocol (LDAP) server(s) 268.

[0054] 2. Dynamically updates and manage the relational database schema

[0055] 3. Use the schema mapper 256 and system data cache 262 toimplement its operations and abstract from the API implementation 252how data is accessed and where it is stored, hiding the fact that thedata is distributed.

[0056] 4. Provide the implicit mapping from the schema of the objectsdefined in XML to the database schema

[0057] The Supported Objects are given below. These objects are the sameas the objects defined in the XML Protocol as used in the digitalidentity server.

[0058] /account (primary object)

[0059] /user (primary object)

[0060] /machine (primary object)

[0061] /account/users (relationship—not extensible)

[0062] /account/machines (relationship—not extensible)

[0063] /machine/users (relationship—not extensible)

[0064] /user/cookies (cookies—not extensible)

[0065] /user/services (services)

[0066] /machine/services (services)

[0067] /account/services (services)

[0068] /user/favorites (collection object)

[0069] /user/addressbook (collection object)

[0070] . . . (etc)

[0071] When a new type of collection object is introduced (such asAddress Book), no new API functions are needed. Only a new object, andits associated XML schema are needed. The data access layer 254maintains objects and their mappings to physical tables automatically,so that no code has to change at the data access layer 254 when a newobject is created. The same is true for new attributes of existingobjects.

[0072] API Implementation

[0073] The API implementation 252 calls only the various parts of thedata access layer 254 to perform the functions it needs, it does notcall any other pieces, nor does it access any database (268, 270, 272A,272B) directly. The data access 254 layer maps each specific digitalidentity API 251 call into the (more general) data access call. Forexample, a CreateEntity API function calls the generic “create” or “set”method in the data access layer 254, after setting up all the rightparameters, and the connection. Similarly, a GetCookies or GetPropertiesAPI function, calls a generic “get” method, after setting up all theparameters for each type of object (see object list above) to get thedata from the database.

[0074] Schema Mapper 256

[0075] The Schema Mapper component 256 maintains the configuration ofthe XML schema objects, and their underlying physical tables. It alsoprovides the data access layer 254 with a way to easily determine how toaccess a given piece of data. Furthermore, the schema mapper 256 storesXML schema blobs in the Command Server 266, allowing the customer toextend and control the schema dynamically (through GUI tools). Finally,the schema mapper 256 stores information about where attributes reside(Database, external Lightweight Directory Access protocol (LDAP), etc).

[0076] System Data Cache 262

[0077] The system data cache 262 minimizes the need to access the Systemdatabase 272A, since it is a global bottleneck. It further storesservergroup information for users/machines/accounts in a data cache 262so that trips to the System database 272A are eliminated wheneverpossible. The system data cache 262 further provides a way for the APIimplementation functions 252 to efficiently discover theuser/machine/account relationships. Finally, the system data cache 262ensures that the in-memory cache is kept consistent with the database,given that there may be multiple digital identity servers 250 behind aload balancer, and the servers need to appear stateless. The function ofproviding consistent state conditions across multiple digital identityservers is accomplished by allowing communication between multipledigital identity servers for notification purposes when an entity isdeleted or moved.

[0078] Scalability

[0079] Each digital identity server 250 has the ability to connect toany datasource in the site, including all Group databases 272B, theSystem database 272A, and all external customer data (LightweightDirectory Access protocol (LDAP) 268, SMS 270, etc). However, eachdigital identity server 250 has the notion of a home server group,namely a group database 272B to which it is “tightly” bound, eitherthrough physical locality, or through logical locality (i.e. it expectsto service a certain subset of users/machines/accounts in the normalcase). The digital identity server 250 optimizes its access to its ownhome server group 272B as much as possible.

[0080] The digital identity server 250 provides less optimized access toother server groups' data for administration functions (such asMoveEntity) and to external customer data. The digital identity server250 has the option to provide access to all functions on other servergroups, if the adapters/Clients do not wish to connect to anotherdigital identity server which is non-optimized. One digital identityserver is able to service several adapters simultaneously. LoadBalancing (when possible) is done between the clients and the adapters.In the alternative, load balancing may be done between the adapters andthe digital identity Engine through the network adapter

[0081] Call-outs to Legacy Data

[0082] The call-out component 260 retrieves data on a read-only basisfrom external (operator-managed) datastores 270. The customer dataretrieval typically occurs as part of an operation like getProperties inthe API. Use of the call-out 260 is dictated by the Schema Mapper 256,which notes where and how individual properties can be retrieved. Thecall-outs are used only for primitive properties of Entities, but may begeneralized to apply to other data (like Services or Collections) aswell. Data structures are discussed in conjunction with FIG. 3 throughFIG. 7.

[0083] As a part of any call-out, the entityid must be converted into anID that is meaningful for the external datastore. The conversion mayinvolve a call into the system database 272A or user database, toretrieve other properties. The conversion activity is performed eitherin the data access layer, or within the specific modules that performthe call-out.

[0084] Similarly, propertyNames needs to be converted into externalattribute names; this information is generally available through thecommand server 266.

[0085] When the call-out returns, the returned data is merged into theresult set that is returned from digital identity (typically a sequenceof PropertyNameValues), and is indistinguishable from other data.

EXTERNAL DATA—LEGACY DATASTORES

[0086] There are two call-outs shown in FIG. 2B: SMS (subscribermanagement system) 260 uses a general function call; LightweightDirectory Access protocol (LDAP) 258 is a special case for whichhigher-level support is provided. Both of these call outs are examplesof the external data i.e. legacy datstores (234 in FIG. 2A).

[0087] SMS Call-out

[0088] The SMS callout mechanism 260 uses a function call to acustomer-provided routine. Typically, the SMS module is called with anentityid and one or more propertyNames. The SMS callout resolves the Id(convert to an external id), and then makes a function call to theexternal routine. In a Java implementation, this routine is typicallyprovided as a .jar file, loaded as a plugin. The argument list forexternal function includes at least external entity ID andpropertyName(s).

[0089] Lightweight Directory Access Protocol (LDAP) Call-out

[0090] The Lightweight Directory Access protocol (LDAP) call-outprovides high-level support for retrieving data from a LightweightDirectory Access protocol (LDAP) repository.

[0091] The data access layer calls the Lightweight Directory Accessprotocol (LDAP) module, supplying information such as the entityid andpropertyName(s). The Lightweight Directory Access protocol (LDAP)call-out converts the entityId into an Lightweight Directory Accessprotocol (LDAP) Distinguished Name (possibly using information from theSystem DB or User DB), and converts the propertyNames into LightweightDirectory Access protocol (LDAP) attribute names (possibly usingconfiguration parameters).

[0092] Using configuration parameters, it then forms and executes acomplete Lightweight Directory Access protocol (LDAP) call to retrievethe data, such as an Lightweight Directory Access protocol (LDAP) URL,and processes the result set.

[0093] In a Java implementation, this Lightweight Directory Accessprotocol (LDAP) client can be implemented on Java Naming DirectoryInterface (JNDI). Most call-outs use the DirContext.getAttributes()method, to retrieve a set of Lightweight Directory Access protocol(LDAP) attribute values, which are merged into the digital identityresult set.

[0094] Besides being easier to use than the more general call-outmechanism, the Lightweight Directory Access protocol (LDAP) moduleenables the data access layer 254 to pool 253 Lightweight DirectoryAccess protocol (LDAP) connections, as it also does for Java DatabaseConnectivity (JDBC) connections.

[0095] Digital Identity Software Development Kit

[0096] The diagram in FIG. 2C shows the sub-components of the SoftwareDevelopment Kit (SDK) and network adapter 288. The Software DevelopmentKit (SDK) 276 and network adapters 288 both convert between the digitalidentity API and the network protocol (XML/HTTP).

[0097] The SDKs implement the digital identity API, hidingimplementation details behind a standard interface. SDKs are deliveredas libraries, which are used by customers who build out-of-process(external) adapters.

[0098] SDKs must be written in the same language as the correspondingadapters, so separate SDKs are required for each language in whichadapters are written. SDKs are required for both Java and C/C++. Javaadapters may be able to run natively (in-process), if theirclient-server protocol allows it. In-process adapters do not requireSDKs.

[0099] The primary function of the SDK is to convert digital identityAPI calls into network-based communication with the digital identityserver. A simplified process description is:

[0100] 1. Call XML Publisher 284 to convert API command and data intoXML.

[0101] 2. Call HTTP module 280 to establish communication with serverthrough connection pool 282; send XML request; receive response.

[0102] 3. Call XML Parser 286 to parse response; convert to API datastructures; return to caller.

[0103] Digital Identity Network Adapter 288

[0104] The network adapter 288 runs in the same process as the digitalidentity server, and services out-of-process adapters. The job of thenetwork adapter 288 is the complement of the SDK 276; it convertsXML/HTTP requests back into digital identity to API function calls. Inthis sense, the digital identity server is using its native networkprotocol as a sort of RPC mechanism for the external adapters to makecalls to the digital identity engine. The extensible markup language(XML) is actually very well suited for this purpose.

[0105] Similar conversions to/from XML (shown as XML Publisher 284 andXML Parser 286) are performed in both the SDK and network adapter. Theseconversions share the same technology base, especially for XML parsing286.

[0106] Adapters

[0107] Each adapter's 274 primary function is to translate thecommunication that it receives from its client in its native protocol tothe Liberate digital identity API. Clients make requests to adapters toperform certain operations such as getting and setting of data. Theserequests are decoded and handled by the adapter, and translated intodigital identity API calls; data returned from the API calls is encodedand sent to the client. As mentioned, adapters may run in-process orout-of-process; the API is identical in either case.

[0108] Compared to in-process adapters, external ones offer advantages(independence of programming language; stability of external process)and disadvantages (potential performance penalty of extra network hop).In general, in-process adapters should be used where possible, forperformance reasons.

[0109] Adapters that rely on HTTP use the same mechanism for decodingand handling the network traffic as the digital identity network adapter(namely an HTTP server such as Apache) 298. A goal of the digitalidentity server is to use a single adapter to service all XML requests,be they from in-process or out-of-process adapters. To facilitateunification, a compatible XML format is adopted.

[0110] CORBA and LDAP adapters

[0111] The digital identity server does not provide native interfacesfor CORBA or Lightweight Directory Access protocol (LDAP). Clients thatuse these protocols require special-purpose adapters. The adaptersimplement the appropriate Server type (CORBA or LDAP), but use digitalidentity protocols on the back end.

[0112] CORBA

[0113] The CORBA adapter is needed to support the User Data Manager,which is a CORBA Client (currently implemented as a Java applet). Likeall CORBA servers, it supports an interface defined in an IDL. IDL hascurrently been defined for the digital identity engine consisting ofabout 40 operations, defined on 7 interfaces (object classes). Thissupports a particular object model, which has since been extended fordigital identity. In order to make the new digital identity featuresaccessible through CORBA, the IDL is extended. The adapter translatesIDL calls into digital identity API calls.

[0114] The CORBA adapter may run either in-process or out-of-processwith respect to the digital identity Engine. An in-processimplementation links the digital identity Engine into the CORBA Serveras a library, which is different from the method of running otherin-process adapters, which are accessed through a web server interface.The out-of-process implementation uses the SDK and network adapter.

[0115] The Digital Identity Object Model

[0116] As shown in FIG. 3, there are three top-level object classes:Accounts 302, Users 306 and Machines 304. These three top-level objectclasses are collectively referred to as Entities. Individual Entitieshave a unique entityid, specified when the Entity is created. Each User306 is associated with exactly one Account. Each Machine 304 isassociated with exactly one Account. As illustrated by the 1 to Nrelationship an account 302 may have a plurality of users 306. Asillustrated by the 1 to M relationship, an account 302 may have aplurality of machines 304. For example, a household CATV account 302 mayinclude several family members as users 306, and have more than one CATVconverter 304.

[0117] All Entities may have primitive Properties. Properties are typed;the current set of types is {string; integer; boolean; binary}. Besidesthe primitive Properties, Entities may have Collection Propertiesassociated with them. Collections are structured objects—i.e., haveprimitive Properties of their own. Collections may have many Instancesfor a given Entity; each Instance has a unique instanceid, which can beused to access that Instance.

[0118] As shown in FIG. 5, the account entity is associated with one ormore attributes 510, services 516 and collections 508. An account entity502 stores the properties of the account and billing information.

[0119] Similarly, FIG. 6 illustrates the machine entity 604 beingassociated with one or more attributes 610, services 616 and collections608. The machine entity 604 represents an interactive device.

[0120] Similarly, the user entity 706 is associated with one or moreattributes 710, services 716 and collections 708. A user entity 706represents the user of an interactive device or application. Inaddition, the user entity 706 is associative with one or more cookies718. As shown in FIG. 4, cookies have special Collection Properties,with particular semantics, such as name 406, path 404, domain 402, value410, expiration 412 and security level 414.

[0121] Besides being associated with particular Entities, CollectionProperties may have values at the global (System) level. Customers maydefine additional Properties for Accounts, Users, Machines, orCollection Properties, and may define additional Collection Properties.Entities have Server Groups, which specify where their data is located.Users and Machines associated with an Account have the same Server Groupas the account.

DIGITAL IDENTITY OBJECT MODEL

[0122]FIG. 8 is a hierarchical representation of the Digital identityobject model. Various types of information are represented in thedigital identity server to support the needs of administrators,applications, set-top boxes, and other users. The information isstructured according to a particular model (schema), which reflects theworld of Accounts, Machines, and Users. Information that is handled bythe digital identity server can be accessed and manipulated in a varietyof ways, including through CORBA, and from the settop box.

ENTITIES AND RELATIONSHIPS

[0123] The primary objects in the system are Entities 802, whichcorrespond to Accounts 806, Machines 808, and Users 810. There are threesubclasses of Entities to represent the three cases listed above:

[0124] Accounts: Represents a billing account. An Account may havemultiple Machine and multiple User entities associated with it.

[0125] Machine: Represents a single set-top box. Each Machine objectmust always have an associated Account.

[0126] User: Represents a User on a set-top box. Each User object mustalways have an associated Account.

[0127] Standard UML notation is used to represent both the digitalidentity object model and the associated CORBA IDL. The boxes in FIG. 8represent classes (CORBA interfaces) of which there are 7 in the system.Each box in FIG. 8 is divided into three regions; the top region showsthe class name; the middle region shows the attributes that are definedin the base schema; the bottom region shows the operations (methods)that are defined in the CORBA IDL.

[0128] The lines among the boxes indicate relationships. The ones witharrowheads are generalizations; the others are associations, with themultiplicity indicated by the numbers at either end.

DIGITAL IDENTITY SERVER GROUPS

[0129] To improve scalability, network operators can create digitalidentity server groups. A deployment can have one or more digitalidentity server groups 902, 904, depending on how the network operatorconfigures the system. Each server group 902, 904 has its ownconfiguration settings and its own database. The use of server groups isconvenient when managing a large number of subscribers.

[0130] Besides a database for each server group, there is a single,shared digital identity system database 906 that can be accessed byevery digital identity server. The system database 906 contains basicinformation for all subscribers, while each server group database 902,904 only contains information about the subscribers in that particulargroup.

DIGITAL IDENTITY ADAPTERS

[0131] Digital identity adapters 908, 910 communicate with the digitalidentity servers 902, 904 across an API 912 that provides a single pointof access to all data in all digital identity servers. This provides thefollowing benefits:

[0132] Different TV Navigator clients (such as TV Navigator Standard andCompact clients) can all access the same digital identity server orserver groups.

[0133] Developers can create custom provisioning applications that usethe services of the digital identity CORBA adapter. These applicationscan also interface to external billing, customer service, and subscribermanagement systems, to interoperate with legacy systems.

[0134] A simple graphical user interface is provided at the digitalidentity console 914, which can access and modify persistent data storedin the digital identity servers. The digital identity console 914 isimplemented as a CORBA client.

[0135] Through the provisioning plugin architecture, digital identityprovides access to external back-end data stores, such as LDAP serversenabling system operators to access legacy data.

[0136] The digital identity architecture supports the development of newclient adapters, as needed for emerging protocols.

[0137] Below are several examples of sample code for provisioning anaccount making requests and providing responses. SAMPLE CODE FORPROVISIONING AN ACCOUNT Transaction.open( ); Account johnsAccount =Account.create(“LondonServerGroup”);johnsAccount.setAttribute(“sysFirstName”, “John”);johnsAccount.setAttribute(“sysLastName”, “Smith”); Machine setTopBox1 =Machine.create(johnsAccount, “macAddr1”); Machine setTopBox2 =Machine.create(johnsAccount, “macAddr2”); User john =User.create(johnsAccount); john.setAttribute(“sysName”, “John”);john.setAttribute(“sysPassword”, “1234”); setTopBox1.addUser(john);setTobBox2.addUser(john); Transaction.commit( ); Example XML Request<XMSG> <AUTH CLASS =“USER” TYPE = “password” ID = “Ryan” TOKEN = “asecret”> <REQUEST OP = “GET”> <OBJ N = “/user” ID =“Ryan”/> </REQUEST></AUTH> </XMSG> Example XML Response <XMSG> <RESPONSE OP = “GET” STATUS= “OK”> <OBJ N = “/user” ID = “Ryan”/> <AT N = “sysFirstName”>Ryan</AT><AT N = “sysLastName”>King</AT> </OBJ></RESPONSE> </XMSG>

What is claimed is:
 1. In a system having an electronic communication device operated by a user, said system further including a remote database and a server on a distributed computing network, a method comprising: entering identification information into said electronic communication device; transmitting said identification information to said server; retrieving personalized information from said database; forwarding said personalized information to said electronic communication device, wherein said electronic communication device is a CATV settop box; and wherein said personalized information is related to said user's CATV subscription account, whereby said CATV settop box is personalized to said user. 